This is kind of dubious, but necessary for performance reasons until we get dependable cross-module specialization. Also has a minor test fix for 32b platforms.

Mark all complex elementary functions inlinable

Cleaning up some comments

… removed from Swift main.

These used to be used by some test appratus, but they are no longer
used and can be removed.

In older toolchains, Float16 is marked unavailable on all mac targets; starting with the 5.4 toolchain, it is available starting in macOS 11.0 when targeting Apple Silicon.

Adjust Float16 availability for Swift 5.4 toolchains.

Update version number in sample code.

Tidying, plus a few small edits. This commit should not include any code changes.

…y-father-lies

80-column formatting for source doc comments

…code

remove workflows, no longer needed.

…-plist

Remove .xcodesamplecode.plist, which prevents editing markdown from Xcode

…ithmetic

Document the Augmented enum in RealModule in advance of 1.0

…r-1.0

Add some documentation for AlgebraicField ops, minor fix for Augmented.

Co-authored-by: Xiaodi Wu <[email protected]>

Co-authored-by: Xiaodi Wu <[email protected]>

Co-authored-by: Xiaodi Wu <[email protected]>

Co-authored-by: Xiaodi Wu <[email protected]>

Co-authored-by: Xiaodi Wu <[email protected]>

Further expand documentation of `reciprocal` with some example use.

Update README.md

These are vestigial, and not needed to support swift-pm.

Refactor complex

Update complex cmake for refactoring.

The standard-library documentation for `trailingZeroBitCount` states:

> If the value is zero, then `trailingZeroBitCount` is equal to `bitWidth`.

Thus, if `T` is not a fixed-width integer type, and `x == 0`, and `y` has more trailing zeros than the representation of `x`, then the gcd calculation will be incorrect.

In particular, the left-shift by `min(xtz, ytz) == xtz` will not “undo” the earlier right-shift by `ytz`,  so the final result will be incorrectly right-shifted by `ytz - xtz`.

To fix this I have added an early exit when `x == 0`. I am not sure if this is the optimal solution, and I’m open to alternatives.

***

This change ensures that `x != 0` at the top of the loop, so I have also converted it from a `while` to a `repeat-while` loop, in order to eliminate a redundant extra comparison on the first iteration.

I don’t know if this actually affects performance, and I’m happy to change it back if that’s preferred.

…entiable conformance.

Move baseline supported tools version to 5.4

GCD bug fix

Minor documentation formatting cleanup.

The conformance was breaking CI testing, because the CI bots use a macOS version that predates availability of the _Differentiation module, and the compiler-generated differentation operations have neither availability attributes nor checks, so any reference to those operations simply crashes in dyld because the library is not present. We can add availability, but that's not really accurate either, because these operations are not actually binary-stable, so while we wouldn't crash in dyld, we also might not work correctly in the future. We could mark them unavailable on Apple platforms, but that's also not quite right (and further means that they're not going to get a lot of attention). The best solution seems to be to remove the conformance (which was never source-stable).

Remove conformance of Complex to Differentiable

Adjust the CMake build system to reflect the recent changes of requiring the explicit linking of libm on Linux platforms.

Update CMakeLists.txt to link math library on Linux.

Link math library on Android too